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Additional Snoop Datalink Types 

Status of this Memo 
This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 

Copyright Notice 
Copyright (C) The Internet Society (2004). 

Abstract 
The snoop file format provides a way to store and exchange datalink 
layer packet traces. This document describes extensions to this file 
format to support new media. 

1. Introduction 
[RFC1761] defines the snoop file format used to store captured 
network packets for tools that capture, display, and interpret 
network traffic. The file format specifies a header containing the 
Datalink Type field that identifies the network’s datalink type. 
This document defines new values for this field, as well as an IANA 
registry for future datalink types. 

2. New Datalink Types 


In addition to the Datalink Type codes listed in [RFC1761], this 
document defines the following type codes for the corresponding 


media: 
Datalink Type Code 
Fibre Channel 16 
ATM 17 
ATM Classical IP 18 
IP over Infiniband 26 


The IP over Infiniband packet format is described in [IPoIB]. 


Sarcar Informational [Page 1] 


RFC 3827 Additional Snoop Datalink Types June 2004 


3; 


6. 


IANA Considerations 


This document created a new IANA registry named "Snoop Datalink 
Types" to hold the various possible 32-bit (4 octet) snoop datalink 
types. This new registry holds the values previously defined in 
[RFC1761] and tabulated below: 


Datalink Type Code 
IEEE 802.3 0 
IEEE 802.4 Token Bus T 
IEEE 802.5 Token Ring 2 
IEEE 802.6 Metro Net 3 
Ethernet 4 
HDLC 5 
Character Synchronous 6 
IBM Channel-to-Channel 7 
FDDI 8 
Other 9 


Additionally, the new registry also holds the values defined above in 
section 2 of this document. 


All new allocations and assignments to this registry starting from 
code 27 will follow the First Come First Served policy outlined in 
[BCP0026]. Type codes up to 26 not defined by this section of the 
document (10-15 and 19-25) are considered reserved. 


Security Considerations 


The addition of new datalink type codes to the existing file format 
poses no known security risks. 
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